A trusted system is defined as a system that is predictable in operation and always functions in an assured known and expected state, even under stress. Trusted systems are based foundationally on a Root of Trust (RoT). RoT can be seen as a set of minimized strongly protected security functions that are always deemed “trustworthy” during system operation. The RoT should be simple enough or sufficiently evaluated that one can be convinced that integrity re-measurement is not required once running RoTs work in unison as a core Trusted Computing Base (TCB) for Trusted Platforms. The TCB is used for highly secure sensitive functions, like cryptographic processing, random number generation, key management, and to verify system integrity on startup (secure boot). The employment of RoTs as a TCB to enable “trusted systems” is a foundational architectural engineering approach, which has been advanced and advocated by the Trusted Computing Group (TCG) in the context of their Trusted Platform Module (TPM). The U.S. semiconductor industry currently employs various types of tamper-detection indicators and various RoT techniques to foster increased trust/confidence in the semiconductor supply chain and increased assurance in the mission development process and source distribution.
However, confidence in asserting the trustworthiness of a FPGA configuration and its functionality during startup and during operation is explicitly more challenging than current static “trust” approaches and implementations currently utilized by vendors for enabling supply chain or development assurances. Given the total reprogrammable nature of FPGA devices, RoTs based on dynamic trusted computing specifications and implementation architectures are required. RoTs are needed not only to provide trusted mechanisms for secure bitstream distribution and the bitstream loading at “start-up/boot-up,” but more importantly, to provide secure RoT mechanisms for continuously monitoring the device's functional integrity during bitstream execution/operation. These RoTs need to verify and report (i.e., attest) FPGA bitstream authenticity during run-time to an outside appraiser tasked with accessing system operational integrity and mission assurance during operation, of which the FPGA is an integral component.
FPGAs typically load a user programming bitstream, which contains a user application, from external storage. Besides requiring a second device, the transmission of the program from the nonvolatile external memory to the FPGA may expose the programming to a potential adversary. A good security best approach to thwart an adversary is to store and retrieve the bitstream in encrypted format, and then decrypt the bitstream within the FPGA, making it inaccessible by an adversary. Authentication of the bitstream, as another important security step, can occur on chip before and/or after the decryption process.
TCG has precedence in specifying RoTs with their TPM. This is the primary industry standard for defining the hardware RoT and the foundation for secure software within personal computers (PCs). The latest TPM, release 2.0, implements RoTs through a secure boot and extended chains of trust to provide a TCB for secure measurement, storage, and some reporting services using a low cost integrated circuit (IC), which is physically attached to the PC motherboard.
The initial and primary purpose of TPM is to ensure host (PC) integrity at startup/boot-up. The TPM precedence has been a natural starting point for the introduction of trusted computing RoT options within FPGAs. However, because of the unwieldly size and scope of TPM, direct adaption for FPGA application is not practical. Nevertheless, a simplified and modified implementation of RoTs based upon a secure boot extension for secure measurement, storage, and reporting has been adapted for FPGA startup.
Consequentially, the majority of current FPGA vendors offer secure boot for initializing their FPGAs. Secure applications can and do use this secure boot to enable RoT for remote secure bitstream update, and to provide and conduct system configuration and bitstream measurement integrity check before and after an update is performed. However, relying on this type of static integrity measurement as a true representation of the device's continued state can be misleading. For example, cyberattacks conducted using dynamically triggered malware would likely be activated between software and firmware updates. Accordingly, an improved approach may be beneficial.